Computer systems operating under heterogeneous platforms cannot always exchange data directly among themselves. Numerous types of commercially available products known collectively as middleware have been developed to facilitate data exchange between disparate computer systems. Instead of communicating directly with each other, computer systems can send data in their native format to the middleware. The middleware then sends the data to another system in a format understandable by the second system. Among the categories of middleware are message-oriented middleware and object request brokers.
If a middleware product is not used, a heterogeneous computer system would typically need to operate in a point-to-point mode, for example using message queuing as point-to-point. Under the point-to-point approach, illustrated in FIG. 1, if six separate and distinct applications 120, 122, 124, 126, 128, and 130 are to communicate, connections 101–115 must be made between every possible pair of systems. This type of configuration is undesirable for several reasons. First, the number of connections is large. The number of connections required in a system of n components is (n2−n)/2. For example, a six component system such as that in FIG. 1 requires (36−6)/2 or 15 connections. Second, the point-to-point mode requires tight coupling between each pair of platforms. That is, if each type of technology uses its own data format, a specifically designed adapter is needed between each pair to allow communication between the two. Third, the point-to-point approach creates vendor dependency. The adapters between platforms must meet the requirements of the manufacturers of each system. If a piece of equipment is replaced, the adapters between the new equipment and all other systems must be redesigned.
The use of middleware allows computer systems to operate in a broker mode, sometimes referred to as a hub and spoke configuration. This approach, as illustrated in FIG. 2, is an improvement over the point-to-point approach. In this configuration, each application 220, 222, 224, 226, 228, and 230 communicates only with the broker 232 thereby reducing the number of connections 201–206 needed. For example, this six-application system would require only six connections, numbered 201–206, as opposed to the fifteen needed for six applications connected in the point-to-point mode. Message-oriented middleware products operating in the publish/subscribe mode are an example of brokering middleware. Since these products can typically send and receive data in the native data formats of the applications they connect, adapters are typically not needed to convert data from the format of the applications to the format of a publish/subscribe engine serving as the brokering hub. This reduces vendor dependency and increases system flexibility over the point-to-point approach.
In the publish/subscribe paradigm, a packet of data in a specified format is called a message. An application that sends a message out is called a publisher and an application that receives a message is called a subscriber. The publisher sends its message to a central hub or publish/subscribe engine and includes information about the content of the message. Subscribers perform a process known as registration in which they inform the publish/subscribe engine about what types of message subject matter they are interested in. The publish/subscribe engine matches the content data from the publishers with the registration data from the subscribers and sends the messages to the appropriate subscribers. In this way, publishers can ensure that messages reach an interested audience and subscribers can ensure that unwanted messages are not received. The transmission of messages under the publish/subscribe approach is done in an asynchronous manner. That is, the publisher and the subscriber do not need to communicate with each other at the same time. The publish/subscribe engine can hold a published message until an interested subscriber retrieves it at a later time. Since applications typically can both send and receive messages, a particular application can act as a publisher and/or a subscriber at various times in the communication process.
Among the commercial products that act as publish/subscribe message-oriented middleware are IBM's MQSeries and Sun Microsystems's Java Message Service (JMS). The MQSeries messaging system is described in more detail in the following reference publications, the entire contents of which are incorporated herein by reference:
MQSeries for AIX V5.0 Quick Beginnings
(http://www.software.ibm.com/ts/mqseries/library/manuals/amqaac/AMQAAC01.HTM)
MQSeries Application Programming Guide
(http://www.software.ibm.com/ts/mqseries/library/manuals/csqzal/CSQZAL01.HTM)
MQSeries Application Programming Reference
(http://www.software.ibm.com/ts/mqseries/library/manuals/csqzak/CSQZAK01.HTM)
MQSeries Using C++
(http://www.software.ibm.com/ts/mqseries/library/manuals/amqzan/AMQZAN01.HTM)
The JMS messaging system is described in more detail in the following reference publications, the entire contents of which are incorporated herein by reference:
Java Message Service API
(http://www.javasoft.com/products/jms)
Java Message Service Documentation
(http://www.javasoft.com/products/jms/docs.html)
Object request brokers are the other major category of middleware and their functions and capabilities have been standardized by the Object Management Group (OMG) in a specification known as the Common Object Request Broker Architecture (CORBA). The CORBA distributed object system is implemented under the CORBA specification from the OMG, Revision 2.0, Revision 2.1, Revision 2.2, and Revision 2.3, all of which are incorporated herein by reference in their entirety. For purposes of this disclosure, a program compliant with CORBA Revision 2.3, 2.2, and 2.1 by definition will be viewed as compliant with CORBA Revision 2.0. Unless otherwise specified, a generic reference to CORBA will be presumed to be OMG's CORBA Services Revision 2.0 and a generic reference to CORBA-compliant or to a CORBA platform or program or system will be viewed as compliant with CORBA Services Revision 2.0
Any one of these publish/subscribe or object oriented middleware products can be used to allow heterogeneous computer systems to communicate with each other. However, communication cannot necessarily be established directly from one of these middleware products to another. In a computer system using more than one of these middleware services, applications that communicate with each other through one service would typically not be able to communicate with applications connected to another service. For example, applications that use MQSeries would typically not be able to communicate with applications using JMS. Likewise, CORBA applications would typically not be able to communicate with either MQSeries or JMS applications. The present invention solves this problem by acting as an intermediary between the middleware services in a manner analogous to the way the middleware services themselves act as intermediaries between disparate individual computer systems.